-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add postcss 8 support #121
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Jakub Freisler <jakub@frsource.org>
Seconding this. It is triggering an CC @boutell |
package.json
Outdated
@@ -60,7 +60,7 @@ | |||
"hash-sum": "^1.0.2", | |||
"lru-cache": "^4.1.2", | |||
"merge-source-map": "^1.1.0", | |||
"postcss": "^7.0.36", | |||
"postcss": "^8.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why version 8.0.0
? I would use version ^8.2.13
or higher.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can change it if you want, but anything with ^
at the beginning will evaluate to the same version (newest one starting with 8.
), so there is no difference
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being more specific can be helpful to signal where the actual requirement is, but you're not wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard to tell whether I should change it or not - would be great to have repo maintainers express their opinion on this one (and the whole pr)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the vulnerability was patched in 8.1.3, IMO we should at least require that version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, bumped to the newest version just now
Signed-off-by: Jakub Freisler <jakub@frsource.org>
Signed-off-by: Jakub Freisler <jakub@frsource.org>
Any news on this? As mentioned here and in #122, Postcss 7 is affected by a Regular Expression Denial of Service vulnerability and an upgrade would be much appreciated. |
@sodatea Any update for this pr? |
Anyone? |
Can we get this merged? It's causing some serious compliance issues owing to a CVE reported recently on postcss <8.4.31 (CVSS 5.3) |
@planetchili This package should generally no longer be required. Upgrade Vue to 2.7 or 3. Vue 2.7 added the @vue/compiler-sfc which, I believe, replaces this package. It also backports some Vue 3-ish support without the need to update packages as it is completely Vue 2.6 compatible. Upgrade to Vue 2.7 in every project you use and remove @vuejs/component-compiler-utils as a dependency and you should be good to go. |
But my team still using Vue 2.6, and we have added some enhancement in it. upgrade to Vue 2.7 or 3+ is solution, but so fit for our situation 😔 |
@justforuse you're saying you can't upgrade from 2.6 to 2.7? Why? What "enhancement" did you make and to what? |
As @abea pointed out here, if you're using webpack and vue 2 you are stuck with vue-loader 15, which still requires this module (component-compiler-utils): It's unclear why vue-loader 16 won't work with Vue 2.x, but it doesn't. You have to use vue-loader 15 and vue-loader 15 has to use this module. So it would have been nice to see this fix published, as part of best-effort maintenance for 2.x. So for the next two weeks and three days, we all have a legitimate point 😆 But after that, there is no more upstream support for Vue 2.x. That includes 2.7.x. The long-term support policy has been published for quite a while. At ApostropheCMS we are heavy users of Vue 2.x, and so are our customers. We have plans to release a version built upon Vue 3's "compatibility build" by the end of this year, but we can't realistically expect all of our customers to migrate their custom admin UI code to that by the end of the year, etc. So we also plan to provide minimal community support for Vue 2.x ourselves if necessary, for a period of time. However, that will take the form of releasing fixes for actual, not perceived security problems, e.g. we can't address every "npm audit" warning, only those that constitute actual risks. The PostCSS 7.x vulnerabilities boil down to this: "if you let end users write PostCSS, they could do bad stuff." ApostropheCMS does not let end users write PostCSS, only developers, so the vulnerability is not relevant. An astute reader will note the Vue team's past comments that Vue hasn't had any actual security issues so far. And security is largely a server-side responsibility, apart from not screwing up basic features like escaping on the front end. So we're not likely to have to do much. But if necessary we will follow through on it. Like you, we have clients who will not find this acceptable — they will want a completely clean So I think that's the best that can be done at this point. It would be nice to see this fix published as a 2.x parting gift, but it's not as if there won't be another npm audit warning about a 2.x dependency soon. To be clear, I greatly appreciate the Vue team's hard work on Vue 2, Vue 3 and the Vue 3 compatibility build, which is a great bridge to 3.x for us. |
@fylzero our team have made a internal version based on Vue 2.6 for CSP reason, and we are not plan to make another for Vue 2.7. so it will be a problem for our old project |
Hi, all We have just upgraded to Vue 3 (using WebPack) and we are also having issues with CVE-2023-44270. It would be really great if this PR could be merged in. |
As noted above, Vue 2.x support has come to an end entirely. There is a firm providing commercial support with the blessing of the Vue team — perhaps you could work with them to get this released, or you could publish this fork to your own private npm registry or use a git dependency on a private repo. But honestly, having been through this... if I were you, I'd be working on a fast Vue 3 migration strategy. Note that the Vue 3 "compatibility mode" can be very helpful with this, although we found it surprisingly smooth to transition without it — the list of things we absolutely had to do was pretty small. Here's the announcement we made after transitioning our own open source product to Vue 3, others might find it helpful: Note: I'm not involved in the Vue team at all, just a fellow user who's been through similar decision-making recently. |
@FRSgit any updates on this? I believe this is the culprit to a security vulnerability that my codebase is having |
As mentioned above Vue 2.x support has ended, if you need Vue 2.x support you can reach out to the commercial support partners. I recommend that you use Vue 3's "compatibility build" to ease your migration to Vue 3 and get that out of the way as soon as you can. |
Like @boutell said - I don't think vuejs will ever approve and merge this PR. It's been 3 years since I've risen this PR and at this point I can only recommend migrating to vue@3 as soon as possible. |
component-compiler-utils has a direct dependency of
postcss@7
. It's been more than a year sincepostcss@8
first stable release, so let's migrate it!Why?
First of all the
postcss
plugin API has changed with version 8. Also, according to docs (didn't check the performance myself), changes which I've done totrim.ts
plugin should speed up whole process.This package was the only one holding my application back from migration to
postcss@8
andtailwind@3
.Changes
The logic of plugins wasn't changed by a bit - this whole PR is only about API differences between postcss 7 and 8. Here is an article about these changes and migration process (have a look at steps 2 & 3).
What do you think?